IBIS Macromodel Task Group Meeting date: 05 April 2016 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis Cisco: Seungyong (Brian) Baek eASIC: * David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: * Steve Parker Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan Maxim Integrated Products: Hassan Rafat Mentor Graphics: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Michael M.: Motion to approve the minutes. - Radek: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: New Redriver Flow: - Discussion: Fangyi said he had nothing new to present. Arpad noted that there had been some discussion about getting a group together off line to discuss the proposal and work on drafting a BIRD, but that he had not seen anything recently. Fangyi noted that after the last discussion Walter had said he wanted to review it and make sure he understood the flow. Fangyi said he would email Walter to check on status. Arpad said he would do the same with Vladimir. BIRD 147.1 and Co-optimization: - Discussion: Ambrish noted that he has a new version nearly ready. He is waiting for feedback from a partner. He said he would ping them for feedback and keep Arpad up to date with respect to the status. GND, reference, and C_comp: - Arpad: Does anyone have any updates or discussion starters on this one? - Michael M.: Are the C_comp improvements waiting on the referencing discussions? - Arpad: I'm not sure, but it was recently mentioned that C_comp is one of the most important topics we face for accurate results with power integrity simulations. - Randy: Walter had a recent email on the ATM reflector on that topic. - It talked about C_comp referencing as something we need to discuss and whether we want the spec to say how that is done or if EDA tools can do what they want to. - Arpad: I was a bit confused about this discussion in last week's meeting. - I recall that this whole C_comp issue came up as part of the ground cleanup effort in the editorial task group, which is itself closely related to the s-parameter referencing issues being discussed in the interconnect group. - I thought the editorial task group was waiting on a resolution of the question about the C_comp reference connection. - Then, near the end of last week's meeting, Walter stated that there's nothing to do as far as changing the spec. - If anyone has a better understanding of where this stands, especially with respect to Michael M.'s comments, let us know. - Michael M. (MM): There are two interlocking issues: - We need a circuit-block to substitute for the simple C_comp. - What is the de-embedding mechanism for the K(t) derivation? - How is it connected or referenced? - Arpad: The circuit block is mostly for putting series elements between the buffer terminal and the pad. Series decoupling caps, for example. - The other aspect is the referencing, specifically the ground. - MM: From the editorial discussion there's a trend to either take the following approach or not: - Take the Device Under Test view of IBIS that Walter was proposing, and go with a single node that serves as the reference node for all the C_comp, Vinl, Vinh, [Pullup Reference], etc. and all the other traditional IBIS keywords. - Mike L. (ML) has produced some nice drawings showing the connection assumptions. - Open questions are whether it's called universal reference node, or it's unnamed, or whether it can be tied to another reference, etc. - Arpad: Your (MM's) recent email added a new twist regarding confusion with the [*** Reference] keywords. - Has that discussion reached a conclusion? - Radek: Those conversations are happening in different mailing lists. - Some are in editorial, interconnect, etc. - Unfortunately, not everyone on this call may have seen all the discussions. - The referencing MM mentioned is that when we do the measurements (DUT) we specify [Pullup Reference], [Pulldown Reference], etc. - ML produced some nice pictures that show voltage sources connected to a common node that is also the reference for the I/O signal. - That is the extension of the DUT measurements described in the spec, and it is valid for non-power-aware IBIS simulations in which the reference terminals are all kept constant. - One bit of controversy in this case is that some say the reference node is node 0 in this case. But, it may or it may not be. What's important is that there is one local reference node that is present in the model. - When you have power-aware simulations and you allow the rail voltages to fluctuate, then it is really important to know where a single C_comp is connected. I have mentioned many times that it should be connected to the common reference for the model, which should be considered the local ground. - That needs to be specified by the model maker. - We need to give the model maker the capability to do that using [Pin Mapping] or some other method. - Otherwise we will keep going in circles and say local ground is the pd_ref or local ground is the gc_ref, and people disagree and we get nowhere. - Arpad: I would like to specifically address one of MM's email's questions regarding [*** Reference] keywords. - Are those keywords defining a node or terminal where a connection is made, or are they defining voltages that must be referenced to something. - My understanding was that we meant voltages and not nodes, and that the assumption, which is not spelled out in the spec, was that the reference was somewhere on the board or VRM or test fixture. - MM: If you look very carefully in the spec at the [Pullup Reference] and [Pulldown Reference] language: [sharing that section of the spec] - [Pullup Reference] explicitly says it is defining a "rail." - [Pulldown Reference] is more confused. It mentions 0V with no indication of what the reference is. - Radek: For the nodes or rails it's probably better not to use those [*** Reference] keywords. - We should use pu_ref, pd_ref, etc., and we already have those terms. - Bob put together a document showing all the various terms we use. - What MM is referring to should probably be cleaned up. - Bob: The [Pulldown Reference] section "rail" language is wrong. - MM: I disagree. - I think the "rail" statement is correct. - It defines a "rail" as a reference for the [Pullup] I-V data. - Change "reference voltage" to "reference" in that sentence and it works. - Then we can add a sentence saying, "The value given here is a value for the voltage on that rail with respect to (need to define what)." - Radek: The language is inconsistent. - If you say it's a rail, then you don't also say voltage. - You have a voltage at the rail. - Arpad: I could see it both ways. - You have a rail with a voltage connected to it. It needn't be exclusive. - MM: I agree that we don't want to use "define" in relationship to the rail. - If we wanted to redo this, we would say: - This provides the voltage value associated with a source connected between the pu_ref node and some "reference node" we need to define. - Arpad: I would suggest using the verbiage "applying a voltage" between the rail(s) defined by these keywords and some reference node, instead of "connecting" a voltage to them. - Arpad: [Sharing slide 2 "Bare Die" from ML's IBIS Model Connection Figures] - I agree with this drawing. All the voltage sources associated with the *_ref terminals are connected to one common GND. - Bob: That GND is the "ground." - We have to define a ground as part of the [Model], whether a node exists for it or not. - That is the reference, i.e. the other side of a voltage declaration, for many keywords. - Radek: That's what I've been saying all along. - We need to have that node. We need to have that reference in the [Model]. - MM: Bob, you meant an accessible node, right? - Bob: No. It can be an implicit node. - MM: Okay, as long as there's a node. - I really want to get away from any concept of a voltage as some number hanging in space. There has to be a reference. - So, we have a reference node here even if we can't access it directly. - Radek: This GND is fine. It does not have to be the earth ground symbol. - Somewhere in your entire circuit you may have a global ground somewhere. - This GND node may be offset or floating with respect to that global ground. - MM: I agree, but I strongly advise we not use "GND" as it causes confusion. - We should call it "reference" or something else and allow the EDA tool to connect to it. - Or, we should use some other symbol so as not to imply that the node is necessarily accessible like the I/O pad. - Radek: It must be accessible. Even I/O is only defined with respect to some reference node, and it must be accessible. It must be in the picture. - Arpad: Walter has a good point when talking about DUT vs. DIA. - As a DUT the GND node could be the test fixture reference. - But we need to spell out where the package model is located on this drawing in an actual simulation. Is it between the sources and the I/V curve boxes, or on the other side of the sources? - Radek: The legacy model was an extension of the signal node through the package to the signal Pin. You had R_pkg, L_pkg, C_pkg. C_pkg was connected to the node shown as GND here (or could be called ref). - It's been like that forever. We may want to clean up the terminology. - MM: If we say that there is a reference node there, do we provide a way to specify it in the model or do we leave it up to the EDA vendor to figure out how that node should be connected? - Can the model maker say, "I want that node to be a Pin, or pu_ref, or..."? - There may be some call to define things like a reference that is only inside the package. - Radek: We need to give the tools to the model makers so they can specify it. - Bob: I disagree. - That GND might be the ground plane reference, and it's the reference for all supplies that are defined internally. - Your pc_ref, gc_ref, etc. could be hooked up to external supplies instead the [* Reference] values. - Radek: Okay, then why do you disagree? - This GND does not have to be absolute ground. - What's important is that [GND Clamp Reference] as a value gives the voltage between the gc_ref terminal and this GND, this reference. - Bob: I agree, but GND can't vary. - Arpad: In this picture I would put a box around the 4 I/V boxes to represent the Die. Then another box could show the package. I could not see a die having ideal sources in real life. That could be made clear. (Note: ML agreed, and the presentation that is posted to the work archive does contain a box around the [Model] elements). - ML: [Sharing his "IBIS Model Connection Figures" presentation.] - Slide 2, "Bare Die": what we have been reviewing. - Slide 3, ECL and PECL. - Only difference is that the pullup and pulldown tables are both connected to the [Pullup Reference]. - Slide 4, includes Package. - Supply sources and test fixture common reference node shown outside of the package. - Where is C_comp connected? - Arpad: I don't want to deal with C_comp now. - As the [* References] go, I would agree with this picture. - I would simply put a box around the I/V curves to clearly indicate the die boundaries. (see Note above, ML agreed and added the box) - In light of MM's question, can we agree to this drawing and figure out how to best describe it? - Bob: We can agree on the partitioning. - There's a model section. - There's a package section. - There is the possibility of internally provided rails, or external rails fed to the [Model] via the package. - The K(t) table is based on fixed absolute voltage references. They are fixed internal references defined within the model. They are fixed "numbers" defined with respect to node 0. We have a lot of data with respect to node 0. - We have to agree there is some local reference from which all of the single valued voltage data keywords are defined, except for the tables that are defined relative to some reference keyword. - Arpad: I think Vinl, Vinh would be examples of these single value parameters. - Originally we only had [Voltage Range], not the [* Reference] keywords. - We assumed the VSS Pins are connected directly to the ground node. - The [Voltage Range] "source" was between the ground pins and the VCC pins. - Because those ground nodes were at 0V with respect to node 0, it went without saying that Vinh, and Vinl were also referenced to node0. - When we introduced the [* References] and added the capability of providing some non-zero values for the [Pulldown Reference] and [GND Clamp Reference] (VSS Pins), we didn't think it through and we forgot about what would happen to Vinh, and Vinl and the other single valued numbers. - We have to find a good way to correct the spec and say those single valued voltages are referenced to something. - I would say it should be the internal pd_ref or gc_ref terminals. - Bob: I think the spec is okay the way it is, and those values get changed and they're referenced to the absolute ground. - Your algorithm doesn't work for some cases. - In a PECL spec, Vinh and Vinl track the pu_ref, not the pd_ref. - The way models are issued now for PECL, we change the numbers around if the rails change. - Arpad: We can put verbiage in the spec with a special case for PECL. - Using node 0 does not make sense. - As Walter stated in an email the other day, it's still a 5V device whether it has + or - 2.5V rails or 1000V and 1005V rails. - Bob: A model at 1000 and 1005V would have Vinl at 1001.5 and Vinh at 1003.5. - Arpad: A model maker wouldn't know if you're going to run it at 1000V and 1005V. - Bob: You shouldn't operate that model well outside the range of the fixed voltages given in the [Model]. - Arpad: I'm not providing a pathological case. - Just like you take ECL and lift it up to the positive supply to make PECL, I could take CMOS and push it into negative and run it between -5 and 0. - Bob: Models being created by model makers today are just created with absolute voltages and you assume the models will be operated in that voltage range. - Radek: But those voltages "values" are with respect to something. - We could make them relative to something other than node 0. - Radek: [Commenting on slide 4] - When you are a DUT there is no package in the picture. - When you are simulating, we have a decision to make. - It will make a difference whether we say pu_ref, gc_ref, etc. - If we give the model maker the opportunity to be precise it will be far better, unless we are willing to just say "it will always be connected to pd_ref, or always gc_ref, ..." - Arpad: Where do we stand now in making a decision about how the spec. should be corrected? - I don't see a problem with saying all the single valued entries should be referenced to the bottom rail (or top rail for ECL, PECL)? - Is there an issue with doing that, or are we all in agreement? - How should we proceed with the editorial work? - Radek: I agree. - We can revisit what we say for PECL/ECL for Vinl and Vinh, because I believe it's not quite correct. But that is definitely part of that work. - Radek: [Referring back to slide 4] - When the device is being simulated, we don't have those fixed supplies. - Voltage rail may vary, and it may vary around those values. - The package is present. - We still need to say what the reference node for the signal pin is, and it is not stated here. - Arpad: In the simulation the rails might be non-ideal. - Radek: Yes, then the supplies shown can't be called [Pulldown Reference], etc. because those are fixed values. - Bob: Yes, [Voltage Range] and [* Reference] are the ideal values. - We don't have those values outside the package. - We have VSS1, etc. that can modulate. - The [Model] itself is based on the ideal values, but it can now take into account variations in the rail ([Composite Current], etc.). - Arpad: Most of the data in IBIS is basically measurement conditions. - Voltage, temperature, process variations, etc. - When you simulate those conditions might change. - Bob: I do still contend that there is some reference for the internal model voltages. - We are changing IBIS if we don't recognize that even the threshold values are with respect to a fixed local reference. - We cannot declare that something tracks one or something tracks another. - CMOS thresholds may be 30% and 70% of the difference of pc_ref and gc_ref. - For some other technology like TTL it might follow the pd_ref. - MM: No one is disagreeing with the need for a reference. - Arpad: We are over time, so we will have to continue. - Thank you all for joining. AR: Fangyi to email Walter to check on the status of his review of the Redriver Flow proposal. AR: Arpad to email Vladimir for the same purpose. AR: Ambrish to check for a collaborator's feedback on his nearly ready new version of the Backchannel proposal. ------------- Next meeting: 12 April 2016 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives